Adjudicating integrated transactions

ABSTRACT

A method for adjudicating and reimbursing a care provider for services provided for a clinical event is provided. The method includes referencing an integrated transaction including a number of clinical data elements, wherein the clinical data elements include clinical event details and electronic medical record data elements associated with a patient. Clinical data elements are used to select medical appropriateness criteria from an appropriateness knowledge base. Thereafter, it is determined that an electronic medical record data element affects the selected medical appropriateness criteria. As a result, the medical appropriateness criteria is adjusted in accordance with the electronic medical record data elements determined to affect the medical appropriateness criteria. The adjusted medical appropriateness criteria is used to determine whether the clinical data element(s) satisfy the adjusted medical appropriateness criteria.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority from U.S.application Ser. No. 13/243,177, filed Sep. 23, 2011, entitled“Adjudicating and Reimbursing Care Providers,” which is a continuationof U.S. application Ser. No. 11/326,746, filed Jan. 6, 2006, entitled“Computerized System and Methods of Adjudicating MedicalAppropriateness,” which is now U.S. Pat. No. 8,050,945, which claims thebenefit of U.S. Provisional Patent Application No. 60/714,508, filedJan. 6, 2005, entitled “Computerized System and Methods of AdjudicatingMedical Appropriateness,” which is assigned or under obligation ofassignment to the same entity as this application, the entire contentsof each application being herein incorporated by reference.

FIELD OF THE INVENTION

Embodiments of this invention relate to the field of healthcareinformation technology systems. More particularly, embodiments of theinvention are directed to a system and methods for generating andprocessing an integrated transaction for supporting the provision of,and adjudication and reimbursement for, healthcare services.

BACKGROUND OF THE INVENTION

While providing the highest level of care in the world, the UnitedStates healthcare system is extremely costly. Nearly $1.7 trillion, orroughly 14% of the gross domestic product, is currently spent onhealthcare. An unacceptable portion of the costs within the UnitedStates healthcare system is attributable to administrative costs. Arecent study found that 31% of the overall healthcare expenditures aredirected to administration costs.

The apparent excess in administrative costs is due to a number ofreasons. For example, the provision of health care has predominantlybeen practiced in a paper-based environment. Claims administration,adjudication, reimbursement, benefits management and otheradministrative and financial processes have also predominantly beenconducted in an inefficient, paper-based environment. These paper-basedsystems are plagued by error, redundancy and friction among the partieswithin the healthcare system.

The opportunity exists for information technology to be more widelyemployed in order to provide automate, improve and integrate clinicaland administrative processes. To this point, clinical and administrativesystems have been successful when employed independently from oneanother. From a clinical perspective, electronic medical records (EMRs)have been used to structure and store patient information in acomprehensive, longitudinal manner so that relevant information isaccessible to care providers at the appropriate time and place. The EMRand other clinical healthcare information technology (HCIT) solutionsreduce the number of errors associated with providing care, and minimizethe time and effort required to document and retrieve details of thecare provided. Other benefits are widely known in the art. From anadministrative perspective, on-line claims submittal and electronic fundtransfer (EFT) technologies demonstrate the potential to impact thereimbursement process. Other administrative benefits are known in theart. However, these systems have not been successfully married to oneanother, and the central component of administrative systems, the claim,does not include the information required to fairly and efficientlyreimburse providers for healthcare services.

In existing systems, the claim in a paper or electronic form isforwarded by the healthcare provider, medical facility or the patient toa payer for processing and payment. Once the claim arrives at the payerinstitution, the process of adjudicating the benefit claim begins inaccordance with the constraints of the policy and plan, and anyagreements between the payer and the provider or facility. Theadjudication of a submitted claim is a process initiated by the payer todetermine the health benefits covered under the benefit plan contract,including its limitations, exclusions, schedule of benefit orreimbursement, managed care provisions or any other entitlements or lackof entitlements. The payer adjudication system analyzes the datasubmitted via the claim and determines whether the claim should be paid,in whole or in part, or be denied.

Once the claim is adjudicated by the payer, an explanation of benefits(EOB) statement is generated with the assigned payments and, ifapplicable, any reasons for nonpayment, and is returned with the paymentto the healthcare provider. Once returned to the healthcare provider,the EOB is manually reviewed to identify any unpaid, underpaid or remarkcodes to compare those codes to the originally submitted claim. Once theEOB is reviewed and any issues identified, the healthcare providerattempts to correct, revise and resubmit the claim. In this step,incorrect codes or non-applicable codes are corrected, incorrectdescriptions of procedures are revised, and the claim is resubmitted tothe payer. The healthcare provider then engages the payer to resolve anydisputed claim issues and further correct or modify the resubmittedclaim. The process may be repeated until all claims have been paid orotherwise resolved.

The existing processes for claim submission and adjudication are laborintensive, time consuming, and provide little assurance that a claimwill be paid. The processes largely ignore the core clinical data andinformation related to the care provided and focus almost exclusively onthe billing codes that summarize the care provided. The processes do notaccount for the condition of the particular patient, the quality of thecare provided or the appropriateness of the care provided given theparticular clinical circumstances surrounding the patient and theencounter. As such, the standards of review are based on generalitiesrather than the scientifically supported evidence regarding theprovision of appropriate, high quality care.

As noted briefly above, a minimal level of information technology hasbeen employed in the claims adjudication process. For example, someadministrative systems allow providers to submit claims forreimbursement electronically. Also, benefits companies provide onlineaccess for verifying eligibility and plan coverage, and determining thestatus of claims and other benefit information. Other existing systemsaddress claims processing from a multi-system perspective plagued byinterfaces, incompatibility and limited functionality. By way ofexample, one software application may be used to edit a claim whileanother software application determines eligibility and yet anothersoftware application addresses revenue management. In these and otherexamples, significant user intervention is required to adjudicate andreimburse the care provider after a claim is produced, which also leadsto inefficiencies and increased administrative costs. Little of thefriction inherent in the manual systems is eliminated by thesecomputerized systems. The clinical information for which the claim issubmitted is sparse, incomplete and largely ignored. As such, theexisting systems are unable to adjudicate and reimburse for care in anefficient, time-saving, and cost-effective way. The cost of providingcare and the administration of care has skyrocketed in spite ofincreased efficiencies that information technology has provided.

There is a need for a system and methods that integrate clinical,financial and payer benefits information and provide a common processfor the provision of care and administration of health care benefits toreduce the medical error and eliminate the variance, waste, delay andfriction in the current healthcare system. There is also a need for atrusted and open automated system for the person receiving care, theprovider, the payers, and others to access. There is a further need tointroduce medically supported evidence in the process of providing andpaying for care to improve the level of care, and allow providers toemploy the best medicine while receiving the appropriate level ofreimbursement for the care provided. The system and methods of thepresent invention address these needs and others evident from thedescription provided below.

SUMMARY OF THE INVENTION

The invention overcoming these and other problems in the art relates inone regard to a system and methods for processing an integratedtransaction for efficient provision of healthcare, and adjudication andreimbursement for the care provided. In embodiments, a method foradjudicating and reimbursing a care provider for services provided for aclinical event is provided. The method includes referencing anintegrated transaction including a number of clinical data elements,wherein the clinical data elements include clinical event details andelectronic medical record data elements associated with a patient.Clinical data elements are used to select medical appropriatenesscriteria from an appropriateness knowledge base. Thereafter, it isdetermined that an electronic medical record data element affects atleast one of the selected medical appropriateness criteria. As a result,the affected medical appropriateness criteria is adjusted in accordancewith the electronic medical record data elements determined to affectthe medical appropriateness criteria. The adjusted medicalappropriateness criteria is used to determine whether the clinical dataelement(s) satisfy the adjusted medical appropriateness criteria.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described in detail below with reference to theattached drawing figures, wherein:

FIG. 1 is a block diagram of an exemplary computing environment for usein implementing the present invention;

FIG. 2 is a flow chart representative of an exemplary computer programfor generating and processing an integrated transaction to reimburse acare provider for a clinical event in accordance with an embodiment ofthe invention;

FIG. 3 is a flow chart representative of an exemplary computer programfor creating the integrated transaction and building the integratedtransaction of FIG. 2 in accordance with an embodiment of the invention;

FIG. 4 illustrates the initial clinical event details of the integratedtransaction in accordance with an embodiment of the invention;

FIG. 5 illustrates the integrated transaction of FIG. 4 aggregated toinclude an organization identifier in accordance with an embodiment ofthe invention;

FIG. 6 illustrates the integrated transaction of FIG. 5 aggregated toinclude a person identifier in accordance with an embodiment of theinvention;

FIG. 7 illustrates the integrated transaction of FIG. 6 aggregated toinclude EHR data elements in accordance with an embodiment of theinvention;

FIG. 8 illustrates the integrated transaction of FIG. 7 aggregated toinclude data elements used to determine the quality of the care providedin accordance with an embodiment of the invention;

FIG. 9 is a flow chart representative of an exemplary computer programfor adjudicating the integrated transaction based on the medicalappropriateness of the care provided during the clinical event inaccordance with an embodiment of the invention;

FIG. 10 is a flow chart representative of an exemplary computer programfor adjudicating the integrated transaction based on the quality of careprovided during the clinical event in accordance with an embodiment ofthe invention;

FIG. 11 is a flow chart representative of an exemplary computer programfor adjudicating the integrated transaction based on the historicalquality of care associated with the clinical event in accordance with anembodiment of the invention; and

FIG. 12 is a flow chart representative of an exemplary computer programfor automatically reimbursing the care provider based on the integratedtransaction in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

The subject matter of the present invention is described withspecificity herein to meet statutory requirements. However, thedescription itself is not intended to limit the scope of this patent.Rather, the inventors have contemplated that the claimed subject mattermight also be embodied in other ways, to include different steps orcombinations of steps similar to the ones described in this document, inconjunction with other present or future technologies. Moreover,although the terms “step” and/or “block” may be used herein to connotedifferent elements of methods employed, the terms should not beinterpreted as implying any particular order among or between varioussteps herein disclosed unless and except when the order of individualsteps is explicitly described.

The present invention provides a computerized system and methods for usein generating and processing an integrated transaction for supportingthe provision of, and reimbursement for, healthcare services. Anexemplary operating environment for the present invention is describedbelow.

Referring to the drawings in general, and initially to FIG. 1 inparticular, an exemplary computing system environment, for instance, amedical information computing system, on which the present inventionsmay be implemented is illustrated and designated generally as referencenumeral 100. It will be understood and appreciated by those of ordinaryskill in the art that the illustrated medical information computingsystem 100 is merely an example of one suitable computing environmentand is not intended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should the medical informationcomputing system 100 be interpreted as having any dependency orrequirement relating to any single component or combination ofcomponents illustrated therein.

The system 100 includes a central computing system 102 communicatingwith one or more care provider locations 104, payers 106 and healthcareconsumers 108. As described below in greater detail with reference toFIGS. 3-8, central computing system 102 includes an initial transactionaggregator 110 for receipt and accumulation of clinical, financial andadministrative data elements. Each integrated transaction is storedwithin a data store 112 containing a number of transactions forprocessing in accordance with embodiments of the invention.

As described below with reference to FIGS. 9-12, the central computingsystem further includes a services component 114 for automaticallyadjudicating each integrated transaction. Services component 114includes an eligibility module 116, an appropriateness module 118 and aquality module 120. Services component 114 also includes a reimbursementmodule 122 for automatically reimbursing, or initiating thereimbursement of, the care provider in real time (or near real time)from one or more payers though the central computing system. Servicescomponent 114 also includes additional modules 124 capable of processingthe integrated transactions for purposes in addition to the servicesprovided by modules 116, 118, 120 and 122.

Healthcare services are provided at any of a number of care providerlocations 104. These locations can be located at medical environments,for example, but not limited to, hospitals, other inpatient settings,pharmacies, a clinician's office, ambulatory settings, testing labs anda person's home environment. In an embodiment, one or more computingdevices 126 are located at, or associated with, each care providerlocation 104 and receive clinical, financial and administrative dataelements for storage at one or more data stores 128 located at, orassociated with, each care provider location. For example, the computingdevices 126 and data stores 128 may be physically located at theprovider's physical locations, at remote locations at which the healthcare information technology systems are hosted for the providers, ordistributed there between. The computing devices 126 communicate withthe central computing system 102 through a network 129 and an interface130.

The data elements may include, for example, a variety of clinical,financial and administrative data elements as described in embodimentsof the invention with reference to FIGS. 4-8. Clinical data elements are“clinical event details” submitted by the provider for the transactionbeing adjudicated and “EHR data elements” that pre-exist the submissionof the particular transaction being adjudicated and are stored in thesystem as described below. For example, clinical data elements include,for example, patient identification data, diagnosis data, patientmorbidity, mortality and recovery rates, drug prescription and otherdrug delivery and management information, and data elements traditionalcaptured at the point of care and stored in an electronic medical record(EMR). Financial and administrative data elements may include hospitalor other occupancy data, supply information, medical staff information,scheduling information, or other types of information related toclinical operations.

Payers 106 are similarly connected to the central computing system 102of the present invention. Payers 106 include without limitation,employers, government entities (such as the Centers for Medicare andMedicaid Services), charities, insurers and secondary insurers. Inembodiments, one or more computing devices 132 associated with eachpayer 106 collect and manage payer data elements that are stored in oneor more data stores 134. The payer data elements include, withoutlimitation, procedure codes, physician identification, insurance orother coverage data including co-pay and deductible amounts, eligibilityrequirements, and benefit reimbursement levels. The computing devices132 communicate with the central computer system 102 through a network136 and an interface 138.

Consumers 108 are also connected to the central computing system 102.Consumers 108 include individuals receiving care and individualsresponsible for the care of others. For purposes of the presentinvention, consumers may also include any of a number of other entitiessuch as financial institutions responsible for an aspect of a consumerobligation. A number of computing devices 140 associated with theconsumers collect clinical, financial and administrative data elementsstored in one or more data stores 142. The computing devices 140communicate with central computer system 102 through a network 144 andan interface 146.

The computing devices at the provider and payer institutions and thecentral computing system are preferably general purpose computingdevices having a server. Components of the servers may include, but arenot limited to, a processing unit, internal system memory, and asuitable system bus for coupling various system components, includingassociated data stores. The system bus may be any of several types ofbus structures, including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus, also known as Mezzanine bus.

The servers typically include therein or have access to a variety ofcomputer readable media, for instance, at the associated data stores andknowledge bases. Computer readable media can be any available media thatcan be accessed by the servers, and includes both volatile andnonvolatile media, removable and nonremovable media. By way of example,and not limitation, computer readable media may comprise computerstorage media and communication media. Computer storage media includevolatile and nonvolatile, removable and nonremovable media implementedin any method or technology for storage of information, such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD), or other optical disk storage, magneticcassettes, magnetic tape, magnetic disk storage, or other magneticstorage devices, or any other medium which can be used to store thedesired information and which can be accessed by a server. Communicationmedia typically embodies computer readable instructions, datastructures, program modules, or other data in a modulated data signal,such as a carrier wave or other transport mechanism, and includes anyinformation delivery media. The term “modulated data signal” means asignal that has one or more of its characteristics set or changed insuch a manner as to encode information in the signal. By way of example,and not limitation, communication media includes wired media, such as awired network or direct-wired connection, and wireless media such asacoustic, RF, infrared and other wireless media. Combinations of any ofthe above should also be included within the scope of computer readablemedia.

Servers may operate in a computer network using logical connections toother general computing devices. Other general computing devices may bea personal computer, router, a network PC, a peer device or other commonnetwork node, and may include some or all of the elements describedabove relative to server. The consumer computing devices 142 willtypically consist of personal computers integrated with data store 140.

A user may enter commands and information into the general computingdevices through input devices, such as keyboards, pointing devices,commonly referred to as a mouse, trackball, or touch pad. Other inputdevices may include a microphone, satellite dish, scanner, or the like.The computing devices may have any sort of display device, for instance,a monitor. In addition to a monitor, the computing devices may alsoinclude other peripheral output devices, such as speakers and printers.

Although many other internal components of server and general computingdevices are not shown, those of ordinary skill in the art willappreciate that such components and their interconnection are wellknown. Accordingly, additional details concerning the internalconstruction of the server and other computing devices need not bedisclosed in connection with the present invention.

Data elements are communicated between the providers, payers andconsumers and the central computing system through networks 129, 136 and144, for instance, via a local area network (LAN) and/or a wide areanetwork (WAN), but may also include other networks. Such networkingenvironments are commonplace in offices, enterprise-wide computernetworks, intranets and the Internet. When utilized in a WAN networkingenvironment, servers may include a modem or other means for establishingcommunications over the WAN, such as the Internet. In a networkedenvironment, program modules or portions thereof may be stored inserver, or data stores, or on any of the general computing devices suchas the remote computers. For example, and not limitation, variousapplication programs may reside on the memory associated with any one orall of the computing devices. It will be appreciated that the networkconnections shown are exemplary and other means of establishing acommunications link between the computers may be used.

The data stores provide storage of computer readable instructions, datastructures, program modules, and other data for the computing devices.As described herein, the data stores may include, for instance, a queryengine such as a SQL engine or other resources to facilitate themaintenance, interrogation and transmission of the data. The data storesmay be or include a large-scale or other database hosting facility, suchas a site including or interfacing to, for example, relational databasessuch as the Oracle™ relational database sold commercially by OracleCorp. or others. Other storage or query formats, platforms or resourcessuch as OLAP (On Line Analytical Processing), SQL, storage area networks(SANs), redundant arrays of independent disks (RAID) or others may alsobe used, incorporated or accessed by data stores, which may be supportedby servers or other resources.

The methods and system of the invention receives data, and providesinformation to adjudicate and reimburse for care provided in response torelevant input and/or actions initiated within the healthcare system.Although the method and system are described as being implemented in aWINDOWS operating system operating in conjunction with a comprehensivehealthcare network, one skilled in the art would recognize that themethod and system can be implemented in any system supporting thereceipt and processing of the relevant data elements and inputs.

An exemplary method 200 for generating and processing an integratedtransaction to reimburse a care provider is illustrated in the flowdiagram of FIG. 2. Initially, at block 202, the method is initiated.Subsequently, at block 204, the clinical event details are combined withtraditional administrative and financial details and aggregated to forminitially an integrated transaction as described below with reference toFIGS. 3-8.

An exemplary method 300 for creating and building an integratedtransaction is illustrated in the flow diagram of FIG. 3. The methodbegins at block 310. Next, at block 312, the system receives initialclinical event details (and traditional administrative and financialdetails) to initiate the transaction. In an embodiment, the clinicalevent details are captured by the care provider at the point of care. Inone example, a number of structured care templates may be used tocapture contemporaneous or near-contemporaneous clinical data elementssuch as laboratory test results, imaging studies, pharmaceuticalprescription or use, clinical outcomes or other data as set forth withspecificity below. That data may be captured and stored into adocumented care note, chart or other record, which may in embodiments bestored to a clinical data store such as data store 128 (FIG. 1), andcombined with existing data in the data store 128 of each provider. Inthis embodiment, when a documented care note is signed and stored withinthe patient record, the care provider is prompted to add any of a numberof clinical event details typically required for processing inaccordance with the present invention that are not already included inthe patient's record.

By way of example, FIG. 4 illustrates a subset of initial clinical eventdetails forming the initial integrated transaction at block 312 of FIG.3. In an embodiment, the clinical event details include, withoutlimitation, person identification (or person identifier), visitidentification, allergies, patient adverse reactions, diagnoses,procedures, problems, medication administrations, and immunizations. Theperson identification includes a number of elements specific to theindividual person receiving care (or “patient”). For example, address,gender, race, communication mechanism list, and marital status for theperson are aggregated and included in each integrated transaction.

Visit identification includes those clinical event details specific tothe individual person's visit to a care provider (primary carephysician, specialist, hospital). For example, visit identificationincludes clinical event details such as admitting reason, admittingdate, discharge, and servicing facility, among others. The clinicalevent details also include medically related information specific to theperson. Information regarding any allergies is aggregated in thetransaction. Allergy-related adverse reactions are also collected andincluded in the integrated transaction.

In addition, clinical event details regarding the clinical diagnoses andthe procedures performed, any medications administered, andimmunizations given to the patient are included in the integratedtransaction. Table 1 includes an exemplary list of clinical eventdetails included in the initial transaction. In this embodiment, anumber of the data elements are defined by Health Level 7's (HL7)Continuity of Care Record (CCR).

TABLE 1 Clinical Event Details Person Identification  Name   First  Middle   Last   Suffix  Mother's Maiden Name  Birth Date and Time Death Date and Time  Gender Code  Race Code  Address List (Home,Business, Etc.)   Address Type Code   City   State/Province   CountyCode   Postal Code   Country Code  Communication Mechanism List (Home,Business, email, Etc.)   Communication Mechanism Type Code  Communication Mechanism  Identifier List (Driver's License Number,SSN, MRN, etc.)   Identifier Type Code   Identifier  Primary LanguageCode  Marital Status Code  Religion Code  Nationality Code  Citizenship Physician List (PCP)   Physician Relationship Type Code   Identifier  First   Middle   Last   Suffix Visit Identification  Identifier  ClassCode  Type Code  Admit Reason  Admit Date/Time  Discharge Date/Time Physician List (Admitting, Attending, Referring, Consulting, etc.)  Physician Relationship Type Code   Identifier   First   Middle   Last  Suffix  Servicing Facility   City   State/Province   County Code  Postal Code   Country Code  Estimated Length of Inpatient Stay  ActualLength of Inpatient Stay Allergies  Allergen Coding Method  AllergenType Code  Allergen Code/Mnemonic/Description  Allergy Severity Code Allergy Reaction Code  Identification Date Patient Adverse Reactions Allergen Coding Method  Allergen Type Code  AllergenCode/Mnemonic/Description  Allergy Severity Code  Allergy Reaction Code Allergy Action Code  Allergy Unique Identifier  Action Reason Sensitivity to Causative Agent Code  Allergen GroupCode/Mnemonic/Description  Onset Date  Onset Date Text  ReportedDate/Time  Reported By  Relationship to Patient Code  Alert Device Code Allergy Clinical Status Code  Statused by Person  Statused byOrganization  Statused at Date/Time Diagnoses  Diagnosis Coding Method Diagnosis Code - DG1  Diagnosis Description  Diagnosis Date/Time Diagnosis Type  Major Diagnostic Category  Diagnostic Related Group DRG Approval Indicator  DRG Grouper Review Code  Outlier Type  OutlierDays  Outlier Cost  Grouper Version And Type  Diagnosis Priority Diagnosing Clinician  Diagnosis Classification  Confidential Indicator Attestation Date/Time  Diagnosis Identifier  Diagnosis Action CodeProcedures  Procedure Coding Method  Procedure Code  ProcedureDescription  Procedure Date/Time  Procedure Functional Type  ProcedureMinutes  Anesthesiologist  Anesthesia Code  Anesthesia Minutes  Surgeon Procedure Practitioner  Consent Code  Procedure Priority  AssociatedDiagnosis Code  Procedure Code Modifier  Procedure DRG Type  Tissue TypeCode  Procedure Identifier  Procedure Action Code Problems  Action Code Action Date/Time  Problem ID  Problem Instance ID  Episode of Care ID Problem List Priority  Problem Established Date/Time  AnticipatedProblem Resolution Date/Time  Actual Problem Resolution Date/Time Problem Classification  Problem Management Discipline  ProblemPersistence  Problem Confirmation Status  Problem Life Cycle Status Problem Life Cycle Status Date/Time  Problem Date of Onset  ProblemOnset Text  Problem Ranking  Certainty of Problem  Probability ofProblem (0-1)  Individual Awareness of Problem  Problem Prognosis Individual Awareness of Prognosis  Family/Significant Other Awarenessof Problem/Prognosis  Security/Sensitivity Medication Administrations NDC Code  Quantity  Quantity Unit Code  Dose  Strength  Strength UnitCode  Interval  Route Code  Date and Time  Provider   Identifier   First  Middle   Last   Suffix Immunizations  CVX Code  Quantity  QuantityUnit Code  Dose  Strength  Strength Unit Code  Interval  Route Code Start Date and Time  End Date and Time  Provider   Identifier   First  Middle   Last   Suffix

The clinical event details are aggregated with administrative andfinancial data associated with traditional claims and submitted to thecentral computer system 102 by the care provider 104 through network 129and interface 130. Interface 130 may reside within the central computingsystem or externally to the system as illustrated in FIG. 1. Theinterface preferably places the data elements received from theproviders in a standard format capable of processing by the servicescomponent 114 of the central computing system. In embodiments, thetransaction is defined in a standard format such as the CCR and employedby all providers accessing the system. Alternatively, conditioningengines may be employed to translate transactions of differing formatsinto a standard format for processing in accordance with the invention.Once the initial set of data elements are received and structured to thestandard format, an initial transaction 150A is defined as shown in FIG.1.

With reference back to FIG. 3, once the integrated transaction 150A isdefined, the system determines at block 314 if there is a uniqueidentifier for the provider and/or organization identified in theintegrated transaction. As illustrated in FIG. 1, initial aggregator 110includes a participation evaluator 152 and a data store 154 containingunique identifiers for providers and organizations known to the centralcomputing system 102. The participation evaluator 152 determines if theprovider is a known provider, and if the organization is a knownorganization, by querying the data store 154. Known providers andorganizations include providers and organizations associated with a planof one of the payers 106 as provided to the central system throughnetwork 136 and interface 138. Providers and organizations that havepreviously submitted transactions also have unique identifiers in thedata store 154.

With reference back to FIG. 3, if either the provider or theorganization does not have a unique identifier, then a new identifier iscreated at block 316. Next, the new identifier is aggregated into theintegrated transaction at block 318. If unique identifiers are found indata store 154 at block 314, then block 318 is bypassed. By way ofexample, FIG. 5 illustrates an integrated transaction including aprovider identifier and an organization identifier as included in theintegrated transaction. The provider identifier for fictitious physicianJohn Smith is 1498000 and the organization identifier for fictitiousorganization State General Hospital is 9988000. Each identifier isstored in data store 154 and included in the integrated transactionrelated to the care provided under the heading entitled OrganizationIdentifier.

Initial aggregator 110 includes an enterprise master person index (EMPI)aggregator 156 and a data store 158 containing unique identifiers forpersons receiving care or otherwise accessing the system. At block 320,the EMPI aggregator determines if a unique person identifier is storedin data store 158 for the patient identified in the integratedtransaction. A person identifier, using enterprise master person index(EMPI) technology known to those of ordinary skill in the art, isestablished for the person and does not change throughout the lifetimeof the person. Known people include people participating in a plan ofone of the payers 106 as provided to the central system through network136 and interface 138. Other people that have previously submittedtransactions to, or otherwise accessed services provided by, the centralcomputing system 102, have unique identifiers in the data store 154. Byway of example, FIG. 6 illustrates the integrated transaction (150B inFIG. 1) including a person identifier. Specifically, in this instance,the person identifier for fictitious person Richard L. Johnson is0267569 in the integrated transaction.

With reference back to FIG. 3, if the person receiving care does nothave a unique identifier as determined at block 320, a new identifier iscreated at block 322. Next, the new identifier is aggregated into theintegrated transaction at block 324. If a unique identifier exists atblock 320, then block 324 is bypassed.

The initial aggregator 110 also includes an electronic health record(EHR) exchange 159 and an EHR data store 160 containing centralizedhealth records for persons interacting with the central computing system102. At block 326, the EHR exchange 159 determines if an electronichealth record exists in the EHR data store for the person identified inthe integrated transaction. If an existing EHR is present, then theintegrated transaction is stored to the EHR at block 328. If an EHR isnot located in the EHR data store 160, then an EHR is created at block328 based on the clinical event details of the integrated transaction.Next, at block 330, the system stores the clinical event details to theEHR data store 160.

Next, at block 332, EHR data elements not present as clinical eventdetails provided by the providers are aggregated to the integratedtransaction. As discussed below, historical EHR data elements may affectthe appropriateness and quality determinations made by servicescomponent 114. These EHR data elements are aggregated into theintegrated transaction for further processing. By way of example, FIG. 7illustrates the integrated transaction (150C of FIG. 1) including anallergy retrieved from the EHR data store 160. Specifically, in thisinstance, the allergy of the patient to penicillin is present in the EHRbut not the initial integrated transaction. The penicillin allergy isaggregated under the Allergies heading (to accompany aspirin). Thepenicillin allergy may be relevant to the adjudication ofappropriateness of patient care and is thus included in the integratedtransaction.

In embodiments, an EHR may be formed for each person interacting withthe system 100 since the transactions of the present invention include acomprehensive set of clinical data elements and the system is adapted toprocess transactions from a number of payers. Care providers may submitintegrated transactions for those clinical events for whichreimbursement is not requested so that the clinical event details can bestored in the EHR data store 160. For example, transactions for cosmeticsurgery and other types of care paid for by the person receiving carecan be added. Also, consumers, care providers and payers may provideinformation to their EHR and have access to the history through thesystem of the present invention as, for example, through an EHR viewermodule provided by services component 114.

Accordingly, the EHR data store 160 may serve as a robust community EHR.The financial incentive of providers to receive reimbursement providesthe requisite incentive for the providers to submit integratedtransaction. By associating each integrated transaction with a uniqueperson identifier and storing the transaction together, an EMR isformed. When several large payer populations are managed with thesystem, the EMR data store results in a community EMR. In embodiments,logic may be employed for updating a single EMR depending on a number ofconditions such as continuity of submitting provider, timing, method fordata capture and the like. In other embodiments, audit trails forupdates may be provided. In other embodiments, feedback may be providedby the system when inconsistent data is being submitted than data in theEHR.

Returning to FIG. 3, at block 334, the system determines if additional,relevant clinical event details are available from one or moreproviders. Some data elements required to complete adjudication may notbe available at the time of care. For example, outcomes and results datarequired to determine the quality of the care provided are oftentimesnot available when the initial transaction is initiated. By way ofexample, FIG. 8 illustrates the integrated transaction of FIG. 7aggregated to include a length of stay of 3.7 days. In this instance,the length of stay may be a relevant indicator of the quality of careprovided as described below with reference to FIGS. 10 and 11.

Table 2 includes an exemplary list of clinical event details related tooutcomes (or results) of the care provided as may be aggregated at step332.

TABLE 2 Observations (Results) Identifier Value Type Code Value UnitsCode Reference Range Abnormal Code List  Abnormal Code Result StatusReference Range Effective Date Date and Time Producer  Identifier Identifier Type Code  First  Middle  Last Responsible Observer Identifier  Identifier Type Code  First  Middle  Last Method Date/Timeof the Analysis

With reference back to FIG. 3, if additional clinical details are notavailable at block 336, the system determines if any additional relevantclinical details are outstanding that may affect adjudication andreimbursement. Some details are required for adjudication andreimbursement and may halt processing. In some cases, as described belowwith respect to FIG. 9, a care provider documents additional clinicalevent details for the integrated transaction after the initialsubmission to demonstrate that the appropriate care was provided. Forexample, a provider may input a justified reason for departing from thegenerally accepted protocol for medically appropriate care. As set forthwith reference to clinical event details related to outcomes, the systemmay similarly query the provider for submission of such justification atblock 334. If received, the system stores the justification in the EHRat block 330 and aggregates the reason as an additional clinical dataelement in the integrated transaction at block 332.

Some clinical event details are less relevant to adjudication, andprocessing of the integrated transaction may be completed in the absenceof these details. For example, additional EHR data elements that changethe standards for medical appropriateness in rare cases are notrequired, and the omission of these EHR data elements may not haltadjudication and reimbursement for care. If no additional clinical eventdetails are outstanding or the outstanding clinical event details wouldnot halt processing of the integrated transaction, the aggregationprocess of FIG. 2 then ends at block 338.

With reference back to FIG. 2, once the data elements (includingclinical event details) are aggregated in the integrated transaction atblock 204, the system accesses plan information (or benefit dataelements) provided by the payers and determines benefit eligibility.Eligibility module 116 includes an eligibility engine 170 and aneligibility data store 172 containing eligibility information from eachof the payers 106. Eligibility engine 170 selectively determines if thecare described in the integrated transaction is eligible forreimbursement under any of the payer plans. The determination is made bymethods known by those of ordinary skill in the art. Data reflectingthis determination is aggregated in the integrated transaction datastore 112. A synchronizer 161 updates the EHR data store 160 whenadditional data is aggregated to the transaction by the provision ofservices by the service component.

Once eligibility is determined at block 206, the medical appropriatenessmodule 118 determines if the care provided is medically appropriatebased on the integrated transaction. An exemplary method 900 foradjudicating the integrated transaction based on the medicalappropriateness is illustrated in the flow diagram of FIG. 9.

Initially, the process begins at block 902. Subsequently, at block 904,the system determines if appropriateness criteria are defined for theclinical event of the integrated transaction. In an embodiment,appropriateness module 118 includes an appropriateness engine 174 and anappropriateness knowledge base 176. Guidelines, standards of care andother normative information are contained in knowledge base 176. Thesemay, for instance, include recommended or best practices for differentcategories of diseases, patients or treatments as well as other clinicalbaseline or objective data. In embodiments, the knowledge base 176 mayinclude or access clinical guidelines published or released by ZynxHealth, Inc. or other content providers. Other sources of objective,evidence or research-based clinical guidelines and standards may beassessed or incorporated, such as for example data published or providedby the Joint Commission on Accreditation of Healthcare Organizations.Other public or private sources or combinations of sources ofclinically-related criteria or guidelines may also be used. At block904, appropriateness engine 174 identifies the relevant clinical dataelements in the integrated transaction to select appropriate criteriafrom the knowledge base 176. If appropriateness criteria do not existfor the clinical event of the integrated transaction, at block 906, thesystem determines that the medical appropriateness is incapable of beingevaluated and stores the determination in the integrated transaction.

If appropriateness criteria are defined for the clinical event for whichthe integrated transaction is generated, the criteria relevant to theintegrated transaction are identified at block 907 by theappropriateness engine 174. Next, at block 908, the system determines ifEHR data elements aggregated in the integrated transaction affect therelevance criteria identified at block 907. As mentioned above, “EHRdata elements” are clinical data elements that pre-exist the initialtransmission of the transaction. If EHR data elements present in theintegrated transaction affect the medical appropriateness criteria, themedical criteria are adjusted at block 910.

If the EHR data elements in the integrated transaction do not affect thecriteria, or after the EHR data elements in the integrated transactionhave been used to adjust the medical appropriateness criteria, thesystem determines at block 912 whether the clinical data elements in theintegrated transaction satisfy the medical appropriateness criteria. Ifthe medical appropriateness criteria are satisfied, the determination isstored to the integrated transaction at block 914 and the adjudicationof medical appropriateness ends at block 915.

If, at block 912, the clinical data elements in the integratedtransaction do not satisfy the medical appropriateness criteria, thesystem notifies the care provider at block 916 that one or more of thecriteria are unsatisfied. Preferably, the notification is made in realtime so that the provider may add additional details regarding the careprovided.

Once the care provider is notified that the medical appropriatenesscriteria have not been satisfied, the system determines if additionalclinical event details are received from the care provider at block 918.For example, the care provider may have inadvertently neglected to inputrelevant clinical event details. If additional clinical event detailsare received, those clinical event details are stored in the integratedtransaction at block 920. Then, the process 900 re-initiates at step 904until a determination of medical appropriateness is made.

If, at block 918, additional clinical event details are not receivedfrom the care provider, the care provider is then given the opportunityat block 922 to explain or justify the care provided or omitted. If thesystem determines that a reason has been received, at block 924, thesystem then determines if the reason is acceptable. If the reason isdeemed acceptable against a pre-defined list of acceptable reasons(stored in the appropriateness knowledge base 170), the reason isaggregated in the integrated transaction and medical appropriatenessadjudication is deemed satisfied and stored at block 914 and thedetermination of medical appropriateness ends at block 915.

If, at block 922, a reason for the care provided is not received, thenthe system determines that medical appropriateness is not satisfied andthe determination is stored to the integrated transaction at block 906.If a reason is received at block 922, but the reason is deemedunacceptable at block 924, the system determines that medicalappropriateness is again not satisfied and stores the determination aspart of the integrated transaction at block 926.

In operation, by way of a number of examples, processes for determiningmedical appropriateness based on the integrated transactions aredescribed herein. In a first example, assume a fictional person requiresarrhythmia management. After the integrated transaction is initiallyaggregated and eligibility determined as described above, medicalappropriateness is adjudicated according to the method 900 of FIG. 9.After the process is initiated at block 902, the system determines ifappropriateness criteria are defined for the clinical event at block904. In this example, at block 907, a number of baseline appropriatenesscriteria are defined for the clinical event, and the system identifiesthese criteria. In this example, the appropriateness criteria indicatesthat certain medication treatments (pre-determined doses, ranges,frequencies and forms) are medically appropriate. Next, at block 908,the system determines if EHR data elements in the integrated transactionaffect the criteria. In this case, the medical evidence suggests that itis medically appropriate to implant a pacemaker for the purpose ofarrhythmia management if the EHR data elements for the person includebradycardia (slow heart beat) and syncope (fainting). If the integratedtransaction includes these observations or conditions, the medicalappropriateness criteria are adjusted to include a pacemaker as anappropriate medical treatment. Next, at block 912, the system determinesif the clinical data elements satisfy the criteria. In this case, drugtreatment, a pacemaker or the combination of both treatments areappropriate. If one or both clinical data elements are documented forthe care provided, then medical appropriateness is satisfied and storedas part of the integrated transaction at block 914.

In another example, a hypothetical person admits to the EmergencyDepartment (ED) complaining of chest pains and shortness of breath. Uponexamination, it is determined that the person is experiencing heartfailure and the care process is initiated to treat the person. In thiscase, a number of baseline appropriateness criteria are defined for thecondition, and the system identifies the criteria at block 907.Specifically, the appropriateness criteria require that aspirin beadministered within the first twenty-four hours of admission. In thiscase, assume the care provider did not administer aspirin within thefirst twenty-four hours of admission, so the medical appropriatenesscriteria are not satisfied at block 912. Next, at block 916, the careprovider is notified in real time that the medical appropriatenesscriteria have not been satisfied. At block 918, the system determines ifadditional clinical event details are received from the care provider.In this case, no additional clinical event details are received. Thus,at block 922, the system next determines if a reason for the careprovided has been received. In this case, provider documents that theperson had taken aspirin at home minutes before presenting at the ED,therefore, a second dose of aspirin would have been inappropriate.Accordingly, at block 924, the system determines that the reason isacceptable. Medical appropriateness is satisfied and stored to theintegrated transaction at block 914.

In another example, reference is made to a genetic test calledSHOX-DNA-Dx developed by Esoterix with a license from Eli Lilly &Company. This test detects mutations and deletions in the SHOX (ShortStature Homeobox) gene which is believed to cause short stature.Blaschke R. J. & Rappold G. A. SHOX: Growth, Leir-Weill and Turnersyndromes. (Review) TEM 11, 227-230. This test was first discovered in1997. In this example, a clinician such as an endocrinologist wouldorder this new genetic test to diagnosis a child with short staturerather than the conventional and expensive testing processes. However,when the SHOX-DNA-Dx test was first introduced, the knowledge base 176of appropriateness module 118 would not include the test as medicallyappropriate to determine whether a person has short stature.

As such, in this fictional example, at blocks 904 and 907, the systemwould identify that the appropriate care is a convention testing forpatients of a certain height and weight. Next, at block 908, the systemwould determine if EHR data elements in the integrated transactionaffect the appropriateness criteria. In this example, clinical dataelements that could affect whether testing is appropriate includecriteria defining heights and ages of the person's family members. Ifthese clinical data elements are stored in the EHR, these data elementsmay indicate that the likelihood of short stature is relatively high orlow in combination with the patient's height and weight, and the medicalappropriateness criteria may be adjusted at block 910 to allow fortesting or disallow for testing.

For the remainder of this example, assume that the clinical dataelements either as submitted (“clinical event details”) or in the EHR(“EHR data elements”) support testing but the medically appropriatetesting technique is the conventional diagnostic testing. Next, thesystem would determine at block 912 if the clinical data elements in theintegrated transaction indicate that conventional testing was performed.Since the new genetic test is not the conventional treatment, the systemwould provide notification to the provider at block 916 that theclinical event details do not satisfy the criteria. In this case, assumethe clinician opts for the new treatment. Since additional clinical dataelements are irrelevant to the decision to use the new treatment, noneare received at block 918. Next, the system would determine at block 922if a reason for care is provided. In this case, the care providerprovides input that a new procedure was employed. In an embodiment, thecare provider interacts through a standard user interface including anumber of reasons for departing from the appropriateness criteriadefined identified at block 907. The user interface preferably includesa free text field for inputting additional reasons. In this case, theuser may select the option that a new genetic test is available. Atblock 924, the system would determine if this reason is acceptable. Thisdetermination may be made based solely on the reason received.Alternatively, the decision may be made based on a combination of otherfactors. In this case, the reason would be deemed appropriate and themedical appropriateness adjudication satisfied at block 914.

In another example, when a new disease is discovered, a standardaccepted set of appropriateness criteria will not be defined. By way ofrecent example, when persons first presented with Severe AcuteRespiratory Syndrome (SARS), the system of the present invention wouldhave determined that appropriateness criteria were not defined at block904. Next, at block 906, the system would determine that medicalappropriateness is undefined.

Systems of the present invention may be configured to automaticallyreimburse for care provided for certain diagnoses. In other embodiments,a care provider may automatically receive reimbursement up to a certainlevel of care of undefined appropriateness. In another embodiment,integrated transactions for which medical appropriateness is unknown maybe placed in a queue for a decision-making group to determine whetherthe care is appropriate. In one example, a real-time collaborationsession is initiated to resolve the outlier cases for whichappropriateness criteria are undefined.

With reference to FIG. 2, once medical appropriateness is adjudicated atblock 208, the system results the initial level of reimbursement atblock 210. In an embodiment, the level of reimbursement is set by theplan information stored in the eligibility data store 172. Inembodiments, the clinical event details are defined at a granular levelassociated with clinical records rather than traditional codes. Thisallows the reimbursement to be set based on the actual care providedrather than a summary. Also, since numerous alternative treatments maysatisfy the medical appropriateness criteria, different levels ofreimbursement may be dictated for the same presenting problem. Ratherthan resulting one level of reimbursement based on the diagnosis code orother course definition of the clinical event, the level ofreimbursement may be dictated by the actual healthcare servicesprovided. While the refined medical appropriateness adjudicationprotects payers for unnecessary costs and healthcare consumers bydefining a number of treatments paths supported by medical evidence andpatient-specific data, the clinical event details may be used to fairlyreimburse providers for care provided.

As long as the care is medically appropriate, the provider will receivereimbursement for the clinical steps required to provide care withoutfinancial penalty to the provider. Consumers are safer since evidence isutilized to determine medically appropriate care and variance isreduced. Payers are protected since inappropriate care is not reimbursedand the provision of appropriate care will eliminate downstream costsdue to bad outcomes. Also, the system may be used to provide the latestmedical information to care providers by updating the medicalappropriateness criteria.

Next, at block 212, the level of reimbursement is adjusted based on thequality of care provided. A first exemplary method 1000 for adjudicatingthe integrated transaction based on the quality of care provided duringthe clinical event is illustrated in the flow diagram of FIG. 10. Themethod 1000 of FIG. 10 adjusts the level of reimbursement based on thequality of care provided for the particular clinical event for which theintegrated transaction originates. A second exemplary method 1100 foradjudicating the integrated transaction based on the historical qualityof care associated with the integrated transaction is illustrated in theflow diagram of FIG. 11. In embodiments of the invention, one or both ofthe methods may be utilized to determine the adjustment in thereimbursement level based on the quality of care provided. Inembodiment, processing and adjudication based on quality, is performedby a quality engine 178 and associated quality knowledge base 180.

With reference to FIG. 10, method 1000 is initiated at block 1002. Next,at block 1004, the system determines if quality criteria are defined forthe clinical event for which the integrated transaction originates. Inembodiments, the quality criteria are organized and stored withinquality knowledge base 180. Quality criteria include any of a number ofmeasurable or observation conditions indicating the relative success ofthe care. The criteria include the presence or absence of a clinicalcondition indicating an outcome. For example, without limitation,criteria include mortality, morbidity, length of visit or stay, onset ofanother condition due to poor care, recurrence, elimination ofpresenting problem, quality of life indicators, patient satisfaction,and unplanned Emergency Department (ED) visits due to poor care.Additional criteria such as those developed by the National Committeefor Quality Assurance (NCQA) and the Joint Commission on Accreditationof Healthcare Organizations (JCAHO).

If the system determines that there are no quality criteria for theintegrated transaction at block 1004, then no adjustment is made to thereimbursement at block 1006. If quality criteria are defined for theintegrated transaction, the particular criteria are identified at block1008. Next, at block 1010, the system determines if the EHR dataelements in the integrated transaction affect the quality criteria. Asset forth by example below, clinical conditions oftentimes affect therelevant measurement for quality. Rules to adjust the clinical criteriabased on the presence or absence of EHR data elements are stored inquality knowledge base 180. In embodiments, these clinical conditionsare stored in the EHR data store 160. Quality engine 178 analyzes theEHR data elements for the patient to determine if any of the rules areapplicable. If EHR data elements in the integrated transaction affectthe quality criteria, the rules are triggered and the criteria areadjusted accordingly at block 1012. If EHR data elements do not affectcriteria as determined at block 1010, block 1012 is bypassed.

Next, at block 1014, the system determines if the relevant clinical dataelements for the quality criteria are present in the integratedtransaction being adjudicated. If the relevant clinical event detailsare not present, the system continues to poll for the receipt of thesedata before a determination is made at block 1014. As set forth in FIG.3 and discussed above, the present invention updates the integratedtransaction at blocks 334 and 336 until all relevant clinical eventdetails required for adjudication are available. As set forth below, theclinical event details evaluated by some quality criteria may bedocumented during the course of care or immediately thereafter. As such,the quality determination may be made in real time and the claimadjudicated on the basis of quality. If absent from the integratedtransaction, a real time query may be made in the bypass loop for thecare provider to document the clinical event details required for thequality adjudication.

Since quality data is oftentimes unavailable at the time care isprovided, quality adjudication may be delayed until after the provisionof care. For instance, the time period between the presentation of acondition and the recurrence of the condition is not available duringthe initial provision of care. In these cases, the quality adjustment isnot made until the recurrence occurs or after a pre-defined periodelapses within which the condition does not recur. In embodiments, thequality portion of the reimbursement may be held until the clinical dataelements required are aggregated in the integrated transaction.Alternatively, the provider may be reimbursed on the assumption that thecare was of appropriate quality, and subsequently debited or creditedfor the quality of care when the appropriate data elements areaggregated to the integrated transaction. Periodic queries of thepersons or care providers may be made to complete the transaction.

Next, at block 1016, the system and method applies the quality criteriaand calculates the quality adjustment. As set forth in the examplesbelow, care of particularly poor quality may result in no reimbursement.More frequently, at block 1016, the quality component 120 applies anadjustment to the base level of reimbursement under the payer plan.Then, at block 1018, the calculation is made and the level ofreimbursement is determined.

By way of a fictional example, a person presents to a care providerseeking treatment for a laceration to the arm causing excessivebleeding. The care provider treats the person by suturing the armlaceration with stitches. At this point, the bleeding has stopped, thelaceration has been treated and the person is sent home. In embodiments,the system and method would determine if quality criteria were definedfor this clinical event of the integrated transaction at block 1004. Thecriteria for this case could simply include the stoppage of bleeding,which would be identified at block 1008. After a determination is madewhether there are relevant EHR data elements at block 1010, and whetherrelevant clinical data elements are included in the integratedtransaction at block 1014, the quality determination is calculated atblock 1016. In this case, the quality criteria would be satisfied and adetermination of the reimbursement level would be complete at block1018.

The exemplary method 1100 for adjudicating the integrated transactionbased on the historical quality of care associated with the integratedtransaction is illustrated in the flow diagram of FIG. 11. The method1100 is initiated at block 1102 by quality module 120 (FIG. 1). Next, atblock 1104, the system determines the type of relevant historicalintegrated transactions required to adjudicate the integratedtransaction. In embodiments, the system will determine the type based onthe clinical data elements of the integrated transaction beingadjudicated. For example, the type of relevant integrated transactionswill oftentimes be limited to similar procedures for similar patients.Also, the type of relevant integrated transactions will be also belimited to those integrated transactions associated with a particularcare provider, the care provider's group or the hospital at which thecare was provided. For example, if the integrated transaction is relatedto a heart bypass surgery, the type may be defined by heart bypasssurgeries performed by an individual surgeon over the last two years. Inanother example, the type may be defined by all heart proceduresperformed by a particular group of doctors for a certain time period.

Next, at block 1106, the system receives (or identifies) integratedtransactions of the appropriate type from the integrated transactiondata store 112. In a preferred embodiment, integrated transaction datastore 112 includes a data warehouse with predefined data marts ofconventional data types to expedite the processing at block 1106.

Next, at block 1108, the system filters integrated transactions lackingquality determinations from the set of integrated transactions receivedat step 1106. Next, at block 1110, relevance criteria are identified. Asset forth in the examples below, some of the filtered set of integratedtransactions may lack relevance due to demographic information or otherpatient-specific clinical details stored in the integrated transactions.Also, some integrated transactions may not be relevant due to advancesin medicine. If the quality criteria have changed based on the medicaladvances, then the care provided under the outdated method is not of therelevant type. The relevance criteria may also limit the set of relevantintegrated transactions to those occurring during a set period of timeor limit the set of relevant transactions to a pre-defined number ofmost recent clinical events.

Next, at block 1112, the system filters the current set of relevantintegrated transactions based on the relevance criteria 1110 to definethe relevant set of transactions upon which quality is used toadjudicate. Then, at block 1114, the system calculates the overallquality of the resulting set of integrated transactions. For example,the individual quality factors as determined by the process of FIG. 11for each of the integrated transactions of the resulting set may beaveraged to calculate an overall quality score.

Next, at block 1116, the system determines the adjustment based on thequality of care as calculated at block 1114. If the factors are averagedat block 1116, then the factor is used. If another calculation isemployed at block 1114 to define the adjustment, an adjustment factor isdetermined at block 1116. Then, at block 1118, the calculation is madeand the level of reimbursement is determined. In another embodiment, thereimbursement to the care provider could be issued as a bonus.Alternatively, a care provider could incur penalties for providing careof poor quality.

In one example, a forty year old male presents to a care provider withacute myocardial infarction. Initially, at block 1104, the systemdetermines that the type of relevant historical integrated transactionsrelated to diseases of the heart in adults 18-44 years of age connectedto this particular care provider. At block 1106, the quality componentreceives the relevant transactions for further analysis. Next, at block1108, the system filters those integrated transactions that lack qualitydeterminations. At block 1110, the quality component then analyzes theintegrated transactions to determine relevance to the originatingintegrated transaction. Data from the Centers for Disease Control andPrevention (CDC) indicates that the average hospital length of stay foradults 18-44 years of age for diseases of the heart is 3.7 days. Next,at block 1112, the system applies the CDC filters (age, heart disease)to define the relevant set of integrated transactions. At block 1114,the system calculates the length of stay for the set of integratedtransactions and determines that this particular care provider averages3.0 days for length of stay. This average is calculated from relevantintegrated transactions from the previous twelve months. Next, at block1116, the system determines the quality adjustment for the provider at alevel of 1.23 by dividing the 3.7 days of the national average by theparticular doctor's average of 3.0 days. Then, at block 1118, the systemapplies this 1.23 adjustment to determine the reimbursement level forthe originating integrated transaction in this example. In additionalembodiments, rather than using length of stay, the actual clinical eventdetails used by clinicians to discharge patients could be evaluated todetermine quality at a granular level.

As set forth above, methods 1000 and 1100 may be used simultaneously.For example, if adjustment factors are determined in both methods, bothfactors may be applied to the base level of reimbursement to account forthe quality of the care provided in the integrated transaction beingadjudicated and the quality of care historically provided by the careprovider.

With reference to the previous example involving a forty year old malepresenting with acute myocardial infarction, the system could make aquality adjustment based on historical transactions available in thecentral computing system. In addition, the system may make a qualityadjustment simultaneously with the provision of care according to FIG.10 for the specific length of stay for the patient. For example, asnoted above, the quality adjustment based on relevant historicalintegrated transactions results in an adjustment factor of 1.23. If theperson also had an actual length of stay of four days, the adjustmentfactor for the actual care may, in embodiments, be 0.93 (or 3.7 days ofthe national average divided by 4.0 days for the actual clinical event).When the historical adjustment factor of 1.23 and the actual factor of0.93 are multiplied, an overall quality adjustment factor of 1.08results for the integrated transaction. As such, if the appropriatelevel of reimbursement for this transaction is $1000, the provider wouldbe reimbursed $1080.

With reference to FIG. 2, the system next determines if the adjudicationcriteria are satisfied at block 214. If the adjudication criteria arenot satisfied, the integrated transaction is routed to a resolutionqueue at block 216. The adjudication criteria may not be satisfied ifthe originating integrated transaction is not eligible forreimbursement, the appropriateness criteria are not satisfied, or thequality factor is below a pre-defined threshold. In embodiments,reimbursement may be automatically refused rather than routed forfurther resolution if the adjudication criteria are not satisfied. Ifthe adjudication criteria are satisfied, then the provider isautomatically reimbursed at block 220 as described below with referenceto FIG. 12.

An exemplary method 1200 for automatically reimbursing the care providerbased on the integrated transaction is illustrated in the flow diagramof FIG. 12. In embodiments, processing in accordance with the method isperformed by reimbursement module 122 and related components. Namely, areimbursement engine of reimbursement module 122 interacts with othercomponents of central computing system 102 and a reimbursement datastore 184 for storing data required to complete and recordreimbursements.

Initially, at block 1201, the reimbursement process is initiated. Next,at block 1202, the system determines the responsibility of a primarypayer. The responsibility is determined based on the plan information ofthe primary payer. The plan information preferably includes anappropriate baseline reimbursement amount for the care provided. Inembodiments, as discussed herein, the reimbursement for each componentof care provided is granular and relates to the actual care provided asdetailed by the clinical details of each originating integratedtransaction. The appropriate reimbursement amounts for each component ofcare documented in the integrated transaction are aggregated todetermine the baseline level of reimbursement, and the baseline isadjusted on quality processing (and medical appropriateness, inembodiments) as set forth herein with reference to FIGS. 1-11. As such,in embodiments, due to the granularity of the transaction, theresponsibility of each payer may be determined by parsing eachtransaction. For example, a first payer may have responsibility forprocedures performed while a second payer has responsibility formedications costs. The system of the present invention could examine theclinical data elements to determine the level of responsibility of eachpayer based on the care provided and plan details. The parsing of thetransaction and the plan details may determine the payer responsibility.

In embodiments of the invention, an initial level of reimbursement isdetermined at block 212 of FIG. 2 and individual payer responsibility at1202 of FIG. 12. In embodiments, the processing to determine the levelof reimbursement may be distributed between block 212 and thereimbursement method as illustrated in FIG. 12, particularly foradjudicating complex transactions.

Next, at block 1204, the provider is automatically reimbursed from anaccount from a primary payer. In embodiments, rather than automaticallyreimbursing the provider, the system initiates the reimbursementprocess. In embodiments, the payer is reimbursed in real-time via anelectronic funds transfer (EFT). The payment details of the EFT areaggregated in the originating integrated transaction. EFT details andEFT processing are known to those of ordinary skill in the art.

Next, at block 1206, the system determines if there are any additionalpayers who may have responsibility for the remaining amount due for theoriginating integrated transaction. Multiple payers such as thegovernment, a secondary insurer, or a charity may have responsibilityfor an individual clinical event. If there is a payer in addition to theprimary payer, the reimbursement responsibility of the additional payeris determined at block 1202. As set forth with respect to the primarypayer, the provider is automatically reimbursed from the additionalpayer at block 1204 and the integrated transaction is updated. Thisprocess continues at blocks 1206, 1202 and 1204 until reimbursements arereceived from each responsible payer. In a preferred embodiment, thesepayments are cumulated and processed in real-time or in near real-timeto the care provider.

Once it is determined at block 1206 that there are no additional payersresponsible for the care provided as detailed in the integratedtransaction, the system subsequently determines the responsibility, ifany, of the person receiving care (or the person responsible forpayment) at block 1208. The responsibility of the person (or responsibleperson) is determined based on the plan details (as included in theintegrated transaction or another component of the system). Forinstance, the person's responsibility may include a relatively smallpayment (co-pay) or a deductible against the responsibility of thepayer(s) as determined at block 1202. Alternatively, the planinformation may require the responsible person to pay a percentage ofthe overall amount of care provided. Next, at block 1210, the systemdetermines if the person has a health spending account (or HSA). Ahealth spending account is a personal account used for healthexpenditures. Examples of health spending accounts include FlexibleSpending Accounts, Health Savings Accounts and Health ReimbursementArrangements. The determination is made by querying one of any number ofdata stores that may include HSA information. In one example, the plandata in the eligibility module 116 includes HSA information for thepersons associated with the plan. Alternatively, the system may queryexternal data stores at the consumer 108 or financial institutions ofthe consumer to determine if the person has an HSA, particularly forHealth Savings Accounts or other consumer-directed vehicles.

If the system determines that the person has an HSA, the system thendetermines whether funds are available in the HSA at block 1212. Iffunds are available, the system determines whether authorization hasbeen given to withdraw HSA funds to pay for the person's responsibilityat block 1214. In an embodiment, the reimbursement module 122 allows theconsumer to establish a standing authorization to withdraw funds fromthe HSA based on any of a number of criteria. For example, the consumermay pre-authorize use of HSA funds for all of the person'sresponsibility. Since the integrated transaction includes acomprehensive set of clinical data elements and additional dataelements, the user may pre-authorize payment from the HSA on a moredetailed basis. In one example, the person may pre-authorizereimbursement for clinical events at a certain provider, of a certaintype, or under a certain threshold payment amount, or any combinationthereof. Additionally, the person may set pre-authorization conditionsbased on the quality (and/or appropriateness) factoring as determined inthe processes of FIGS. 9-11. For example, authorization may be limitedto care meeting for which quality is particularly high. Theseauthorization criteria may be defined by interaction with thereimbursement module 122 through network 144 such as through a websiteor portal.

If the system is authorized to use HSA funds at block 1214, then thefunds are used to reimburse the provider and the integrated transactionis updated at block 1216. If authorization has not been providedpreviously, at block 1218, the system determines if authorization isreceived directed for this particular integrated transaction. In anembodiment, the person may provide authorization at the care provider'ssite. This authorization may be provided by providing a password orpersonal identification number (PIN) similar to a conventional debittransaction. If authorization is received at block 1218, then the fundsare used to reimburse the provider and the integrated transaction isupdated at block 1216.

Next, at block 1220, the system determines if the person has additionalfinancial responsibility. If not, then the reimbursement is complete andthe process of FIG. 12 ends at block 1222.

If the system determines at block 1210 that the person does not have anHSA, or funds are not available at block 1212, or authorization to usefunds is not received at block 1218, or that the person has additionalresponsibility at block 1220, then the system determines if a debitaccount or credit card account is available at block 1224. In anembodiment, the person provides this information to the reimbursementmodule 122. Alternatively, the information may be stored as part of thereimbursement data store 184.

If account information is available, the system determines ifauthorization is received for the integrated transaction at block 1226in one of a number of ways known in the art. If authorization isreceived, the provider is automatically reimbursed and the integratedtransaction is updated to include details related to the reimbursementsuch as amount, time, date and the like. If bank debit or credit cardinformation is not available or if authorization is not received to usea bank debit or credit card, the integrated transaction is updated atblock 1228 and the reimbursement process ends at block 1230. Ifautomated reimbursement has not satisfied the amount due to the careprovider, follow-up and reimbursement for the unpaid balance is theresponsibility of the provider or provider institution.

Returning to FIG. 2, once the care provider is reimbursed at block 220as described above, the process ends at block 222.

The system and methods of the present invention provide a number ofadvantages. For example, the ability to aggregate payer-based healthcare-related financial data, provider created clinical data, and medicalevidence into a common platform has the potential to transform themanner by which care is delivered. The centralized operation reduces theredundant investment in information technology at the payers, providersand consumers, and allows each of the foregoing to monitor theinformation sourced from one another. The manual processing andreprocessing described in the background are obviated. The process ofreimbursement is simplified. Providers have common access to the bestclinical evidence, and the payers provide incentive to the providers tofollow the best evidence. The aggregation of all of the integratedtransactions in the central system creates a robust electronic medicalrecord for the consumer, and a comprehensive data source from whichresearch and community-based services may be provided. The inventionthus reduces administrative costs and increases the quality of care bymarrying patient-specific data, plan data from multiple payers and bestmedicine.

The foregoing description of the invention is illustrative, andmodifications in configuration and implementation will occur to personsskilled in the art. Other hardware, software or other resourcesdescribed as singular may, in embodiments, be distributed, and similarlyin embodiments resources described as distributed may be combined. Forexample, the data stores in the central computing system may be storedin a single referential data base. The scope of the invention isaccordingly intended to be limited only by the following claims.

What is claimed is:
 1. One or more computer readable storage mediahaving computer-executable instructions stored thereon that executes amethod in a computing environment, the method comprising: referencing anintegrated transaction including a number of clinical data elements,wherein the clinical data elements comprise clinical event detailselectronically documented by the care provider at a point of care forthe clinical event for which reimbursement is sought and electronicmedical record data elements associated with a patient from anelectronic medical record data store of a central computing systemhaving historical electronic medical record data elements received froma plurality of sources; using one or more clinical data elements toselect medical appropriateness criteria from an appropriatenessknowledge base; determining that one or more of the electronic medicalrecord data elements affect the selected medical appropriatenesscriteria; adjusting the medical appropriateness criteria in accordancewith the one or more of the electronic medical record data elementsdetermined to affect the medical appropriateness criteria; and using theadjusted medical appropriateness criteria to determine whether theclinical data elements satisfy the adjusted medical appropriatenesscriteria.
 2. The media of claim 1, wherein the method further comprisesidentifying the one or more clinical data elements to select medicalappropriateness criteria based on relevance to the clinical event forwhich reimbursement is sought.
 3. The media of claim 2, wherein theselected medical appropriateness criteria are defined for a particularcondition of the patient.
 4. The media of claim 2, wherein the selectedmedical appropriateness criteria are relevant to the integratedtransaction.
 5. The media of claim 1, wherein the method furthercomprises storing the determination of whether the clinical dataelements satisfy the adjusted medical appropriateness criteria.
 6. Themedia of claim 1, wherein when the clinical data elements are determinedto satisfy the adjusted medical appropriateness criteria, reimbursementis initiated.
 7. The media of claim 1, wherein when the clinical dataelements are not determined to satisfy the adjusted medicalappropriateness criteria, notifying the care provider that one or moreof the adjusted medical appropriateness criteria are unsatisfied.
 8. Themedia of claim 7, wherein the care provider is notified in real-timethat the one or more of the adjusted medical appropriateness criteriaare unsatisfied.
 9. The media of claim 8 further comprising receivingone or more additional clinical event details pertaining to the careprovided at the point of care.
 10. The media of claim 9, wherein the oneor more additional clinical event details are stored in association withthe integrated transaction.
 11. The media of claim 8 further comprisingreceiving an explanation or a justification for not satisfying theadjusted medical appropriateness criteria.
 12. The media of claim 11further comprising determining that the explanation or the justificationis acceptable and that the adjusted medical appropriateness criteria aresatisfied.
 13. A method in a computing environment, the methodcomprising: referencing an integrated transaction including a number ofclinical data elements, wherein the clinical data elements compriseclinical event details electronically documented by the care provider ata point of care for the clinical event for which reimbursement is soughtand electronic medical record data elements associated with a patientfrom an electronic medical record data store of a central computingsystem having historical electronic medical record data elementsreceived from a plurality of sources; identifying one or more qualitycriteria associated with the integrated transaction; determining thatone or more of the electronic medical record data elements affect aquality criterion of the one or more quality criteria; adjusting thequality criterion in accordance with the one or more of the electronicmedical record data elements determined to affect the quality criterion;and applying at least the adjusted quality criteria to determine therelative success of the care provided to the patient.
 14. The method ofclaim 13, wherein the one or more quality criteria are defined for theclinical event.
 15. The method of claim 13, wherein each of the one ormore quality criteria comprises a measurable or observable conditionindicating relative success of the care provided to the patient.
 16. Themethod of claim 15 wherein each of the one or more quality criteriacomprises a mortality, a morbidity, a length of visit or stay, an onsetof another condition, a recurrence, an elimination of a presentedproblem, a quality of life indicator, a patient satisfaction indicator,or a combination thereof.
 17. The method of claim 13, wherein thequality criterion is adjusted in accordance with predetermined rulesbased on a presence or absence of an electronic medical record dataelement.
 18. The method of claim 13, wherein the determined relativesuccess of the care provided to the patient is used to calculate anadjustment to a base level of reimbursement identified for anappropriate payer plan.
 19. The method of claim 18, wherein thecalculated adjustment is applied to the base level of reimbursementidentified for the appropriate payer plan to result in an adjusted levelof reimbursement.